1<div id="Working-directory-storage"></div> 2<div class="header"> 3<p> 4Next: [[cvs: The administrative files#The administrative files|Intro administrative files]], Previous: [[cvs: How data is stored in the repository#How data is stored in the repository|Repository storage]], Up: [[cvs: The Repository#The Repository|Repository]] |[[cvs: Index#SEC_Contents|Contents]]||[[cvs: Index#Index|Index]]|</p> 5</div> 6 7---- 8 9<div id="How-data-is-stored-in-the-working-directory"></div> 10=== How data is stored in the working directory === 11 12 13<div id="index-CVS-directory_002c-in-working-directory"></div> 14While we are discussing <small>CVS</small> internals which may 15become visible from time to time, we might as well talk 16about what <small>CVS</small> puts in the ‘<tt>CVS</tt>’ directories 17in the working directories. As with the repository, 18<small>CVS</small> handles this information and one can usually 19access it via <small>CVS</small> commands. But in some cases it 20may be useful to look at it, and other programs, such 21as the <code>jCVS</code> graphical user interface or the 22<code>VC</code> package for emacs, may need to look at it. 23Such programs should follow the recommendations in this 24section if they hope to be able to work with other 25programs which use those files, including future 26versions of the programs just mentioned and the 27command-line <small>CVS</small> client. 28 29The ‘<tt>CVS</tt>’ directory contains several files. 30Programs which are reading this directory should 31silently ignore files which are in the directory but 32which are not documented here, to allow for future 33expansion. 34 35The files are stored according to the text file 36convention for the system in question. This means that 37working directories are not portable between systems 38with differing conventions for storing text files. 39This is intentional, on the theory that the files being 40managed by <small>CVS</small> probably will not be portable between 41such systems either. 42 43;‘<tt>Root</tt>’ 44: This file contains the current <small>CVS</small> root, as described in [[cvs: Telling CVS where your repository is#Telling CVS where your repository is|Specifying a repository]]. 45 46<div id="index-Repository-file_002c-in-CVS-directory"></div> 47<div id="index-CVS_002fRepository-file"></div> 48;‘<tt>Repository</tt>’ 49: This file contains the directory within the repository which the current directory corresponds with. It can be either an absolute pathname or a relative pathname; <small>CVS</small> has had the ability to read either format since at least version 1.3 or so. The relative pathname is relative to the root, and is the more sensible approach, but the absolute pathname is quite common and implementations should accept either. For example, after the command 50 51<div class="example" style="margin-left: 3.2em"> 52 cvs -d<nowiki> :</nowiki>local:/usr/local/cvsroot checkout yoyodyne/tc 53</div> 54 55: ‘<tt>Root</tt>’ will contain 56 57<div class="example" style="margin-left: 3.2em"> 58 :local:/usr/local/cvsroot 59</div> 60 61: and ‘<tt>Repository</tt>’ will contain either 62 63<div class="example" style="margin-left: 3.2em"> 64 /usr/local/cvsroot/yoyodyne/tc 65</div> 66 67: or 68 69<div class="example" style="margin-left: 3.2em"> 70 yoyodyne/tc 71</div> 72 73: If the particular working directory does not correspond to a directory in the repository, then ‘<tt>Repository</tt>’ should contain ‘<tt>CVSROOT/Emptydir</tt>’. <div id="index-Emptydir_002c-in-CVSROOT-directory"></div> <div id="index-CVSROOT_002fEmptydir-directory"></div> 74 75<div id="index-Entries-file_002c-in-CVS-directory"></div> 76<div id="index-CVS_002fEntries-file"></div> 77;‘<tt>Entries</tt>’ 78: This file lists the files and directories in the working directory. The first character of each line indicates what sort of line it is. If the character is unrecognized, programs reading the file should silently skip that line, to allow for future expansion. 79 80: If the first character is ‘<code>/</code>’, then the format is: 81 82<div class="example" style="margin-left: 3.2em"> 83 /<var>name</var>/<var>revision</var>/<var>timestamp</var><nowiki>[</nowiki>+<var>conflict</var><nowiki>]</nowiki>/<var>options</var>/<var>tagdate</var> 84</div> 85 86: where ‘<code><nowiki>[</nowiki></code>’ and ‘<code><nowiki>]</nowiki></code>’ are not part of the entry, but instead indicate that the ‘<code>+</code>’ and conflict marker are optional. <var>name</var> is the name of the file within the directory. <var>revision</var> is the revision that the file in the working derives from, or ‘<code>0</code>’ for an added file, or ‘<code>-</code>’ followed by a revision for a removed file. <var>timestamp</var> is the timestamp of the file at the time that <small>CVS</small> created it; if the timestamp differs with the actual modification time of the file it means the file has been modified. It is stored in the format used by the ISO C asctime() function (for example, ‘<code>Sun Apr 7 01:29:26 1996</code>’). One may write a string which is not in that format, for example, ‘<code>Result of merge</code>’, to indicate that the file should always be considered to be modified. This is not a special case; to see whether a file is modified a program should take the timestamp of the file and simply do a string compare with <var>timestamp</var>. If there was a conflict, <var>conflict</var> can be set to the modification time of the file after the file has been written with conflict markers (see [[cvs: Conflicts example#Conflicts example|Conflicts example]]). Thus if <var>conflict</var> is subsequently the same as the actual modification time of the file it means that the user has obviously not resolved the conflict. <var>options</var> contains sticky options (for example ‘<code>-kb</code>’ for a binary file). <var>tagdate</var> contains ‘<code>T</code>’ followed by a tag name, or ‘<code>D</code>’ for a date, followed by a sticky tag or date. Note that if <var>timestamp</var> contains a pair of timestamps separated by a space, rather than a single timestamp, you are dealing with a version of <small>CVS</small> earlier than <small>CVS</small> 1.5 (not documented here). 87 88: The timezone on the timestamp in CVS/Entries (local or universal) should be the same as the operating system stores for the timestamp of the file itself. For example, on Unix the file’s timestamp is in universal time (UT), so the timestamp in CVS/Entries should be too. On <small>VMS</small>, the file’s timestamp is in local time, so <small>CVS</small> on <small>VMS</small> should use local time. This rule is so that files do not appear to be modified merely because the timezone changed (for example, to or from summer time). 89 90: If the first character of a line in ‘<tt>Entries</tt>’ is ‘<code>D</code>’, then it indicates a subdirectory. ‘<code>D</code>’ on a line all by itself indicates that the program which wrote the ‘<tt>Entries</tt>’ file does record subdirectories (therefore, if there is such a line and no other lines beginning with ‘<code>D</code>’, one knows there are no subdirectories). Otherwise, the line looks like: 91 92<div class="example" style="margin-left: 3.2em"> 93 D/<var>name</var>/<var>filler1</var>/<var>filler2</var>/<var>filler3</var>/<var>filler4</var> 94</div> 95 96: where <var>name</var> is the name of the subdirectory, and all the <var>filler</var> fields should be silently ignored, for future expansion. Programs which modify <code>Entries</code> files should preserve these fields. 97 98: The lines in the ‘<tt>Entries</tt>’ file can be in any order. 99 100<div id="index-Entries_002eLog-file_002c-in-CVS-directory"></div> 101<div id="index-CVS_002fEntries_002eLog-file"></div> 102;‘<tt>Entries.Log</tt>’ 103: This file does not record any information beyond that in ‘<tt>Entries</tt>’, but it does provide a way to update the information without having to rewrite the entire ‘<tt>Entries</tt>’ file, including the ability to preserve the information even if the program writing ‘<tt>Entries</tt>’ and ‘<tt>Entries.Log</tt>’ abruptly aborts. Programs which are reading the ‘<tt>Entries</tt>’ file should also check for ‘<tt>Entries.Log</tt>’. If the latter exists, they should read ‘<tt>Entries</tt>’ and then apply the changes mentioned in ‘<tt>Entries.Log</tt>’. After applying the changes, the recommended practice is to rewrite ‘<tt>Entries</tt>’ and then delete ‘<tt>Entries.Log</tt>’. The format of a line in ‘<tt>Entries.Log</tt>’ is a single character command followed by a space followed by a line in the format specified for a line in ‘<tt>Entries</tt>’. The single character command is ‘<code>A</code>’ to indicate that the entry is being added, ‘<code>R</code>’ to indicate that the entry is being removed, or any other character to indicate that the entire line in ‘<tt>Entries.Log</tt>’ should be silently ignored (for future expansion). If the second character of the line in ‘<tt>Entries.Log</tt>’ is not a space, then it was written by an older version of <small>CVS</small> (not documented here). 104 105: Programs which are writing rather than reading can safely ignore ‘<tt>Entries.Log</tt>’ if they so choose. 106 107<div id="index-Entries_002eBackup-file_002c-in-CVS-directory"></div> 108<div id="index-CVS_002fEntries_002eBackup-file"></div> 109;‘<tt>Entries.Backup</tt>’ 110: This is a temporary file. Recommended usage is to write a new entries file to ‘<tt>Entries.Backup</tt>’, and then to rename it (atomically, where possible) to ‘<tt>Entries</tt>’. 111 112<div id="index-Entries_002eStatic-file_002c-in-CVS-directory"></div> 113<div id="index-CVS_002fEntries_002eStatic-file"></div> 114;‘<tt>Entries.Static</tt>’ 115: The only relevant thing about this file is whether it exists or not. If it exists, then it means that only part of a directory was gotten and <small>CVS</small> will not create additional files in that directory. To clear it, use the <code>update</code> command with the ‘<code>-d</code>’ option, which will get the additional files and remove ‘<tt>Entries.Static</tt>’. 116 117<div id="index-Tag-file_002c-in-CVS-directory"></div> 118<div id="index-CVS_002fTag-file"></div> 119<div id="index-Sticky-tags_002fdates_002c-per_002ddirectory"></div> 120<div id="index-Per_002ddirectory-sticky-tags_002fdates"></div> 121;‘<tt>Tag</tt>’ 122: This file contains per-directory sticky tags or dates. The first character is ‘<code>T</code>’ for a branch tag, ‘<code>N</code>’ for a non-branch tag, or ‘<code>D</code>’ for a date, or another character to mean the file should be silently ignored, for future expansion. This character is followed by the tag or date. Note that per-directory sticky tags or dates are used for things like applying to files which are newly added; they might not be the same as the sticky tags or dates on individual files. For general information on sticky tags and dates, see [[cvs: Sticky tags#Sticky tags|Sticky tags]]. 123 124<div id="index-Notify-file_002c-in-CVS-directory"></div> 125<div id="index-CVS_002fNotify-file"></div> 126;‘<tt>Notify</tt>’ 127: This file stores notifications (for example, for <code>edit</code> or <code>unedit</code>) which have not yet been sent to the server. Its format is not yet documented here. 128 129<div id="index-Notify_002etmp-file_002c-in-CVS-directory"></div> 130<div id="index-CVS_002fNotify_002etmp-file"></div> 131;‘<tt>Notify.tmp</tt>’ 132: This file is to ‘<tt>Notify</tt>’ as ‘<tt>Entries.Backup</tt>’ is to ‘<tt>Entries</tt>’. That is, to write ‘<tt>Notify</tt>’, first write the new contents to ‘<tt>Notify.tmp</tt>’ and then (atomically where possible), rename it to ‘<tt>Notify</tt>’. 133 134<div id="index-Base-directory_002c-in-CVS-directory"></div> 135<div id="index-CVS_002fBase-directory"></div> 136;‘<tt>Base</tt>’ 137: If watches are in use, then an <code>edit</code> command stores the original copy of the file in the ‘<tt>Base</tt>’ directory. This allows the <code>unedit</code> command to operate even if it is unable to communicate with the server. 138 139<div id="index-Baserev-file_002c-in-CVS-directory"></div> 140<div id="index-CVS_002fBaserev-file"></div> 141;‘<tt>Baserev</tt>’ 142: The file lists the revision for each of the files in the ‘<tt>Base</tt>’ directory. The format is: 143 144<div class="example" style="margin-left: 3.2em"> 145 B<var>name</var>/<var>rev</var>/<var>expansion</var> 146</div> 147 148: where <var>expansion</var> should be ignored, to allow for future expansion. 149 150<div id="index-Baserev_002etmp-file_002c-in-CVS-directory"></div> 151<div id="index-CVS_002fBaserev_002etmp-file"></div> 152;‘<tt>Baserev.tmp</tt>’ 153: This file is to ‘<tt>Baserev</tt>’ as ‘<tt>Entries.Backup</tt>’ is to ‘<tt>Entries</tt>’. That is, to write ‘<tt>Baserev</tt>’, first write the new contents to ‘<tt>Baserev.tmp</tt>’ and then (atomically where possible), rename it to ‘<tt>Baserev</tt>’. 154 155<div id="index-Template-file_002c-in-CVS-directory"></div> 156<div id="index-CVS_002fTemplate-file"></div> 157;‘<tt>Template</tt>’ 158: This file contains the template specified by the ‘<tt>rcsinfo</tt>’ file (see [[cvs: Rcsinfo#Rcsinfo|rcsinfo]]). It is only used by the client; the non-client/server <small>CVS</small> consults ‘<tt>rcsinfo</tt>’ directly. 159 160 161---- 162 163<div class="header"> 164<p> 165Next: [[cvs: The administrative files#The administrative files|Intro administrative files]], Previous: [[cvs: How data is stored in the repository#How data is stored in the repository|Repository storage]], Up: [[cvs: The Repository#The Repository|Repository]] |[[cvs: Index#SEC_Contents|Contents]]||[[cvs: Index#Index|Index]]|</p> 166</div> 167This document was generated on <i>a sunny day</i> using [http://www.nongnu.org/texi2html/ <i>texi2html</i>]. 168